I don't think we need to move anything to database to properly handle passwords. It smells like a refactoring of the setup scripts which is now a collection of shell, python and perl scripts. Of course this can be done totally independently of the containerization of the server.

As you can see from my request, a huge refactor is exactly what I propose. How do you suggest removing password limitations?

I think one requirement is, that we need some passwords in clear text. Hashing them is not an option.
The one we can handle as hashes, are already stored in that way.
I think all the limitations are coming from cases where we need the password in clear text as we use it to login to a service, like login to the database.

@mcalmer can we enumerate which passwords we need in clear text and for which usage?
So we can evaluate the risk in the correct way.

any news on this?

We have password to authenticate against the DB itself in rhn.conf .
We ask also for a password for a self generated SSL Certificates. But they are not stored permanently.
We need them only to feed the commands at generation time.
We have other passwords stored in the DB to authenticate against SCC, VMware or Cloud (virtual-host-gatherer) container registries or RMT server in the cloud.